前言
在軟體工程領域，當我們談論系統整合時，通常預設系統之間可以透過 RESTful API、JSON 或 gRPC 輕鬆對話。然而，走進真實的醫院場域，資訊架構往往截然不同。
傳統醫療院所內部運作著龐大且年代久遠的核心系統——HIS（Hospital Information System，醫院資訊系統）。這些系統通常以高度封閉的關聯式資料庫建立，各模組（掛號、批價、檢驗、護理、藥局）之間多使用自訂資料庫語法或私有協定通訊。
當臨床前線需要導入行動護理資訊系統（NIS, Nursing Information System）、智慧床邊照護儀器或遠距醫療時，往往面臨嚴峻的「資訊孤島（Data Silos）」困境。
在這 30 天的鐵人賽中，將以工程師的視角，從零探討醫療資料標準化的痛點，並使用現代 Web 技術棧（Node.js / TypeScript）實作一套符合 HL7 FHIR 國際標準 的智慧護理資訊系統後端與資料交換架構。

傳統醫療資訊交換的兩大痛點

1. 點對點串接（Point-to-Point Spaghetti）
   傳統醫療資訊交換最常依賴 HL7 v2（Health Level Seven Version 2） 協定。
   HL7 v2 誕生於 1980 年代末期，採用管道符號（⁠|⁠）與帽子符號（⁠^⁠）作為分隔符的文字訊息（Delimited Text）。例如一條病患入院訊息（ADT-A01）：
   MSH|^~&|HIS|HOSPITAL|NIS|STATION|20260915150000||ADT^A01|MSG00001|P|2.3
   PID|||12345678^^^HOSPITAL^MR||WANG^XIAO-MING||20000101|M
   PV1||I|3F^301^1

這種格式存在以下實務挑戰：
過度寬鬆與高度客製化： 雖然定義了段落（Segments），但允許各家廠商自由使用 ⁠Z-Segments⁠（自定義欄位）。同一份資料，A 廠商與 B 廠商解析出來的欄位語意經常完全不同。
網狀串接難以維護： 每增加一個新系統（例如行動生理量測推車），就必須為該系統與 HIS 之間拉一條客製化的剖析（Parsing）管道，形成難以維護的架構泥淖。

2. 異質資料庫模型與語意落差
   不同醫療次系統對同一概念的定義常有歧異。
   以「體溫」為例：
   HIS 門診系統可能定義為 ⁠TEMP_VAL DECIMAL(4,1)⁠，單位預設為攝氏；
   加護病房（ICU）生理監視器可能將體溫分為肛溫、腋溫、額溫，並以華氏記錄；
   檢驗科系統甚至使用自定義字串儲存檢驗狀態。
   當資料跨系統彙整時，缺乏統一的臨床語意編碼（如 LOINC、SNOMED CT），導致前端系統在呈現病人體溫趨勢圖時，必須寫滿防呆與條件轉換邏輯。

次世代解方：HL7 FHIR 的出現
為了解決 HL7 v2 的鬆散與 HL7 v3 規格過於龐大難以落地的問題，HL7 組織推出了 FHIR（Fast Healthcare Interoperability Resources，讀音同 Fire）。
FHIR 汲取了現代 Web 開發的核心標準：

1. RESTful 架構導向： 每個醫療實體都是一個 URL 資源（例如 ⁠GET /Patient/12345⁠、⁠POST /Observation⁠）。
2. 主流序列化格式： 原生支援 JSON 與 XML，對現代全端工程師極度友善。
3. 組件化（Resource-based）： 將複雜的醫療流程拆解為 140+ 個原子化的 Resource（如 ⁠Patient⁠、⁠Encounter⁠、⁠Observation⁠、⁠MedicationRequest⁠）。
4. 擴充機制（Extensibility）： 核心 Resource 僅保留 80% 醫療系統通用的核心欄位，其餘 20% 透過嚴格驗證的 ⁠Extension⁠ 進行擴充，兼顧一致性與彈性。
   專案目標：打造現代化 NIS 核心與 FHIR 交換閘道
   這 30 天，我們不只談論規格理論，而是要落地打造一個 「微服務/模組化護理資訊系統（NIS）核心」。
   核心技術架構
   語言與執行環境： Node.js + TypeScript
   Web 框架： Express
   內部資料庫： PostgreSQL（模擬臨床關聯式資料儲存）
   標準交換層： HAPI FHIR JPA Server（Docker 容器化）
   測試與驗證工具： Postman、FHIR Validator
   系統架構概念圖
   [ 護理人員行動平板 / 介面 ]
   │ (REST / JSON)
   ▼
   [ NIS 後端 API (Node.js/Express) ]
   │ │
   ▼ ▼
   [ 內部 PostgreSQL ] [ FHIR Adapter 資料轉換層 ]
   (高頻體徵/醫囑核對) │ (FHIR RESTful API)
   ▼
   [ HAPI FHIR Server / 電子病歷交換中心 ]

未來 30 天路徑規劃
本系列文共分為四大模組：

1. 模組一：醫療資訊標準化與環境建置（Day 1–6）
   解析 FHIR 核心 Resource（Patient, Practitioner, Observation）並架設在地化 HAPI FHIR Docker 環境。
2. 模組二：護理資訊系統（NIS）業務與資料塑模（Day 7–13）
   深入病房實際工作流：動態床位管理、時序體溫單（TPR Sheet）、醫囑給藥三讀五對邏輯。
3. 模組三：後端 API 開發與 FHIR 整合實戰（Day 14–21）
   使用 TypeScript 實作 Adapter Pattern，將內部關聯式資料轉換為合規 FHIR Bundle，並實作臨床異常警示引擎（NEWS 早期預警評分）。
4. 模組四：前端呈現、安全防護與部署上線（Day 22–30）
   實作行動端 TPR 曲線視覺化、條碼核對前後端串接、HIPAA 資料去識別化、AuditEvent 稽核日誌與 Docker 完整編排。
   小結
   醫療資訊化並非單純把紙本表單搬到螢幕上，而是如何透過標準化資料結構，讓跨系統資料流轉變得安全、可靠且具備擴展性。
   Day 2，我們將正式進入 HL7 FHIR 的核心設計理念，拆解 Resource 結構、JSON Schema 規範與 Profile 機制，為後續的系統開發建立堅實的基礎知識！